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H.248/MEGACO Registration Procedures 
Abstract 


This document updates the H.248/MEGACO IANA Package registration 
procedures in order to better describe the Package registration 
process and to provide a more formal review and feedback process. 


Status of This Memo 


This document specifies an Internet Best Current Practices for the 
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 
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1. Introduction 


Since the initial development of H.248/MEGACO, a number of 
organizations have made use of the H.248/MEGACO protocol Package 
mechanism in order to allow a certain function to be controlled by 
H.248/MEGACO. The H.248/MEGACO Package mechanism was introduced, in 
part, to allow organizations who had an in-depth knowledge in a 
particular functional area to independently produce a Package on this 
functionality. This acknowledged the fact that neither the IETF 
MEGACO Working Group nor the ITU-T Study Group 16 possessed in-depth 
knowledge in all areas. Whilst this approach has been successful in 
the number and range of Packages produced, in some cases these 
Packages were/are not fully aligned with H.248/MEGACO principles. 
Once a Package has been published and registered, it is problematic 
to rectify any issues. 


The introduction of problems/inconsistencies was caused, in part, by 
the fact that the Packages were not fully reviewed by H.248/MEGACO 
experts. In fact, the IANA H.248/MEGACO registration process did not 
actually specify that an in-depth review should take place. 


The current H.248/MEGACO Package registration process was defined 
when the ITU-T Study Group 16 and the IETF MEGACO Working Groups were 
both active in H.248/MEGACO standardization and produced nearly all 
the registered Packages. Packages were reviewed in the IETF MEGACO 
Working Group and the Working Group chair was the IESG-appointed 
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expert in charge of the review of the requests for H.248 Package 
registration. This meant that H.248 Packages underwent an informal 
review before being registered. However, this has changed. 


The current situation is that now the IETF MEGACO Working Group is 
disbanded and new H.248/MEGACO development typically occurs through 
Question 3 of ITU-T Study Group 16 (notwithstanding email discussion 
on the IETF MEGACO mailing list). This move to ITU-T-defined 
Recommendations is discussed in [RFC5125]. 


Given this situation, it is appropriate that the H.248/Package 
definition and IANA registration rules are updated to introduce a 
formal review step before the Package registration process is 
completed and, ideally, before the Package is published. This 
process will only be applicable to public Packages. 


As part of the Package development process, Package developers are 
encouraged to send their Package for review to the ITU-T Study Group 
Question Rapporteur responsible for the H.248 sub-series of 
Recommendations (ITU-T Question 3 of Study Group 16 at the time of 
writing). When registering the Package with IANA, Package developers 
are required to send a copy of the Package for review by the IESG- 
appointed expert. It is recommended to register the Package before 
final approval by the group in question, in order to solicit feedback 
on the quality of their Package. Wherever possible, this review will 
be done in conjunction with other H.248/MEGACO experts (e.g., in 
ITU-T Q.3/16 and/or the MEGACO mailing list). 


The existing IANA Package registration process is a two-step process. 
When Packages are first registered, they receive the status of "In 
Progress (IP)". This allows Package developers to request a 
PackageID before the document is fully approved. When the document 
is approved, then a change of status to "Final" may be requested. 

The new procedure introduces the step that the IESG-appointed expert 
is consulted before a change of status is made. If the Package has 
been reviewed and is acceptable, then the status may be changed to 
"Final". However, if the Package has not been provided for review or 
has outstanding comments, then the status SHALL remain at "IP". 


The goal of the updated text is to define a process that provides a 
timely technical review of Packages to ensure that H.248/MEGACO 
Packages are of good quality and to minimize duplication. 


The "Error Code", "ServiceChange Reason", and "Profile Name" 


registration procedures have been included for completeness and to 
make explicit the role of the IESG reviewer. These procedures align 
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with the considerations documented in [H248amml1] and with [RFC3525] 
(with the exception of Profile Names, which did not appear in the 
[RFC3525] version). 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Formal Syntax 


The following syntax specification uses the Augmented Backus-Naur 
Form (BNF) as described in [RFC5234]. 


Text-encoded PackageIDs shall conform to the "PackageName" encoding 
in H.248.1 [H248amm1] Annex B, which is repeated below for 
convenience: 


Copyright (c) 2009 IETF Trust and the persons identified as authors 
of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions 
are met: 


- Redistributions of source code must retain the above copyright 
notice, this list of conditions and the following disclaimer. 


- Redistributions in binary form must reproduce the above copyright 
notice, this list of conditions and the following disclaimer in 
the documentation and/or other materials provided with the 
distribution. 


- Neither the name of Internet Society, IETF or IETF Trust, nor the 
names of specific contributors, may be used to endorse or promote 
products derived from this software without specific prior 
written permission. 


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 
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THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 


PackageName = NAME 
NAME = ALPHA *63(ALPHA / DIGIT / " ") 


Note: A digit is not allowed as the first character of a Package 
name. 


4. Security Considerations 


Updating the IANA H.248/MEGACO Package registration procedures has no 
additional security implications. Security for the H.248/MEGACO 
protocol over IP transports is discussed in H.248.1 Section 10 
[H248amm1]. 


As of this date, there have been no recorded security issues arising 
out of the registration or use of Packages. Whilst Packages may 
define extra procedures and code points, these are done within the 
framework of the core H.248.1 specification. It is not possible to 
update the H.248.1 core protocol through a Package specification. 

The use of the H.248.1 core protocol is agreed upon between a Media 
Gateway Controller (MGC) and a Media Gateway (MG). H.248 
ServiceChange procedures establish a H.248 control association 
between the MGC and MG. To establish an association, there must be a 
level of trust between the MGC and MG. In the context of this 
control (and trust) association, the elements 
(properties/signals/events/statistics) from the Packages are conveyed 
between the MGC and MG. An MGC or MG will only act upon elements 
that it knows. If it does not understand a PackageID or Package 
element, then an error response is returned only in the context of 
the control association. 


If a malicious Package specification is implemented in an MGC or MG, 
it would be unlikely to cause problems. As H.248 is a master slave 
protocol, if the malicious Package was implemented in the MGC and not 
the MG, there would be no action because the MG would not understand 


the PackageID (and elements). If the malicious Package was 
implemented on the MG, there would be no effect because the MGC would 
never command the MG to use it. If the malicious Package was 


implemented in both the MGC and MG, then there's a wider, non-H.248 
issue in that someone has managed to install software on both the MGC 
and the MG. It is highly unlikely for such a person to ask IANA for 
a PackageID when they could use any one they want. 
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Therefore, it is in this respect that updates to the IANA 
H.248/MEGACO Package registration procedures are deemed to have no 
additional security impacts. 


Requesters and the Expert Reviewer should ensure that the Package 
does not introduce any additional security issues.  Requesters for 
public Packages for a particular standards development organization 
must be authorized by that organization to request a Package 
registration. 


5. IESG Expert Reviewer Considerations 


For public registered Packages, Error Codes, ServiceChangeReasons, 
and Profile Names, review by an Expert Reviewer is required before 
IANA performs a registration. Private Packages do not require the 
same level of review. The sections below outline the considerations 
for Expert Review. 


5.1. Appointment of the IESG H.248/MEGACO Expert 


The IESG shall remain responsible for allocating the H.248/MEGACO 
expert. It is recommended that this person be involved in ongoing 
H.248/MEGACO development. As such, it is recommended that 
identification of the IESG expert be done in consultation with the 
ITU-T Question/Study Group responsible for the H.248 sub-series of 
Recommendations (ITU-T Q.3/16 at the time of writing). 


5.2. Package Registration Procedure 


Package requesters are encouraged to review their work against 
H.248.1 Section 12 [H248amml1], "Package Definition", and are 
encouraged to use the "Package Definition Template" provided in 
H.248.1 Appendix II. 


The process for registering a public Package is deemed to be 
"specification required" as per [RFC5226]. As such, once the initial 
checks occur, Package requesters for public Packages under 
development shall send the Package text to IANA. They are also 
encouraged to send the package to the ITU-T Question/Study Group 
responsible for the H.248 sub-series of Recommendations (ITU-T Q.3/16 
at the time of writing) for review. Updated contact information can 
be found in the latest version of the H.248 Sub-series Implementors' 
Guide. This should occur as soon as practicable after the rough 
draft of the definition is completed and at least before the Package 
is approved, in order to ensure the Package is consistent with H.248 
methodologies and Package-design principles. 
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In order to register private Packages, a specification is not 
required but is encouraged. 


Package requesters are encouraged to request registration as early as 
practicable in the design process, to reserve a binary ID. Binary 
IDs shall be published in the document defining the Package. 


Once the initial or final request for a Package registration is 
received by IANA, it will be forwarded to the IESG-appointed expert 
for review. During the review, the input Package and details will be 
compared to the Package template for completeness, as well as being 
compared against protocol syntax and procedures. It will be compared 
against existing work to see that it does not duplicate existing 
functionality. It will be reviewed to see that any potential 
security issues are addressed. The Expert Reviewer will then work 
towards a resolution of any issues with the Package requester. The 
IESG-appointed expert may complete the review in consultation with 
other H.248 experts (i.e., currently Question 3 of ITU-T Study Group 
16 and via email to IETF MEGACO email list). If the Package is 
deemed suitable, the IESG-appointed expert shall issue a statement 
indicating approval, copied to IANA. 


The IESG Expert Reviewer will ensure the following considerations are 
met to register a Package with the IANA: 


1) A unique string name, unique serial number and version number are 
registered for each Package. The string name is used as the 
PackageID for text encoding. The serial number is used as the 
PackageID for binary encoding. Public Packages MUST be given 
serial numbers in the range 0x0001 to Ox7fff. Private Packages 
MUST be given serial numbers in the range 0x8000 to Oxffff. 

Serial number 0 is reserved. The unique string name and unique 
serial number MAY either be requested by the Package requester or, 
if not requested, assigned by the IANA. 


2) The Package requester shall provide a contact name and an email 
and postal address for that contact. The contact information 
shall be updated by the defining organization as necessary. 


3) The public Package requester shall provide a reference to a 
document that describes the Package, which should be public: 


a) The document shall specify the version of the Package that it 
describes. 
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b) If the document is public, it should be located on a public web 
server and should have a stable URL. The site should provide a 
mechanism to provide comments and appropriate responses should 
be returned. 


C) If the document is not public, it must be made available for 
review by the IESG-appointed expert (without requiring a non- 
disclosure agreement (NDA)) at the time of the application. 


Note: The document does not have to be publicly available at the 
time of the registration request; however, the document shall be 
provided and available for review by the IESG-appointed expert. 
Once approved by a standards body, the Package SHOULD be made 
publicly available, however the Package MAY remain not public. 


For private Packages, a contact email address for the Package 
registration shall be provided. 


4) Packages registered by other than recognized standards bodies 
shall have a minimum Package name length of 8 characters. 


5) Package names are allocated on a first-come, first-served basis if 
all other conditions are met. 


Status - "In Progress" indicates that the Package has not been fully 
reviewed and approved and, therefore, may contain errors or may not 
be consistent with H.248 principles. "Final" indicates that the 
Package has been reviewed and approved and is stable. New Packages 
shall be registered with a status of "IP". Once the Package has been 
finalized (i.e., approved according to the procedures of the Package 
requester's organization), they should contact IANA in order to 
update the status to "Final". 


Once the IESG-appointed expert has determined that the registration 
is appropriate, they will advise the IANA to register the Package. 


The IANA will assign a serial number to each Package meeting the 
conditions of registration (except for an update of an existing 
Package, which retains the serial number of the Package it is 
updating), in consecutive order of registration. 


5.3. Error Code Registration Procedure 


Error Code requesters shall send a request to the IANA to register 
the Error Code. Documentation addressing the considerations below 
shall be provided (i.e., specification required as per [RFC5226]). 
The IANA shall then forward the request to the IESG-appointed expert 
for review. 
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The following considerations shall be met to register an Error Code 
with IANA: 


1) 


An error number and a one-line (80-character maximum) string are 
registered for each error. 


A complete description of the conditions under which the error is 
detected shall be included in a publicly available document. The 
description shall be sufficiently clear to differentiate the error 
from all other existing Error Codes. 


The document should be available on a public web server and should 
have a stable URL. 


Error numbers registered by recognized standards bodies shall have 
3- or 4-character error numbers. 


Error numbers registered by all other organizations or individuals 
shall have 4-character error numbers. 


Only the organization or individual that originally defined it (or 
their successors or assigns) can modify an error-number 
definition. If the modification leads to a change in the Error 
Code number, Error Code name or error string, the Error Code 
modifier shall send a request to IANA to register the update. 

This request shall be treated as a new Error Code request, which 
will involve an Expert Review. 


Once the IESG-appointed expert has determined that the registration 
is appropriate, they will advise the IANA to register the Error Code. 


5.4. 


ServiceChange Reason Registration Procedure 


ServiceChange Reason requesters shall send a request to the IANA to 
register the ServiceChange Reason. Documentation addressing the 
considerations below shall be provided (i.e., specification required 
as per [RFC5226]). The IANA shall then forward the request to the 
IESG-appointed expert for review. 


The following considerations shall be met to a register ServiceChange 
Reason with IANA: 


1) 


A reason number and a one-phrase (80-character maximum) unique 
String are registered for each reason. 
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2) A complete description of the conditions under which the reason is 
used shall be included in a publicly available document. The 
description shall be sufficiently clear to differentiate the 
reason from all other existing ServiceChange Reasons. 


3) The document should be available on a public web server and should 
have a stable URL. 


Once the IESG-appointed expert has determined that the registration 
is appropriate, they will advise IANA to register the ServiceChange 
Reason. 


5.5. Profile Name Registration Procedure 


Profile Name requesters shall send a request to the IANA to register 
the Profile Name. Documentation addressing the considerations below 
shall be provided. The IANA shall then forward the request to the 
IESG-appointed expert for review. 


The following considerations shall be met to register a profile with 
IANA: 


1) A unique string name and version number (version may be omitted 
when the Profile Name contains a wildcard) is registered for each 
profile. 


2) A contact name and email and postal address for that contact shall 
be specified. The contact information shall be updated by the 
defining organization as necessary. 


3) Profiles registered by other than recognized standards bodies 
shall have a minimum Profile Name length of 6 characters. 


4) Profile Names containing a wildcard "*" on the end of their names 
shall be accepted if the first 6 characters are fully specified. 
It is assumed that the organization that was issued with the 
Profile Name will manage the namespace associated with the 
wildcard.  IANA shall not issue other profiles names within 
"name*" range. 


All Profile Names are first-come, first-served if all other 
conditions are met. 


Once the IESG-appointed expert has determined that the registration 
is appropriate, they will advise IANA to register the Profile Name. 
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6. IANA Considerations 


This document describes an updated Package registration procedure. 
[RFC5226] has been considered in making the updates. This document 
does not alter the tabular Package, Error Code, and ServiceChange 
Reason information in the H.248/MEGACO Packages registry. 


The "Error Code", "ServiceChange Reason", and "Profile Name" IANA 
considerations have been included for completeness. These 
considerations align with the considerations documented in H.248.1 
[H248amm1] and with [RFC3525] (with the exception of Profile Names, 
which did not appear in the [RFC3525] version). 


6.1. New IANA Package Registration 
On the request for an initial or final Package registration, the IANA 
shall forward the received information (i.e., the Package text 
(specification required as per [RFC5226])) to the IESG-appointed 
expert for review (see Section 5.2). 
After the review, when instructed by the IESG-appointed expert, the 
IANA shall register the following information in the "H.248/MEGACO 


Packages" registry as described below: 


1. Serial Number (identity used for Binary Encoding, also known as 
Binary ID) 


2. Text Name (identity used for Text Encoding, see Section 3 for the 
syntax) 


3. Package version 
4. Extension information - Binary ID and Package version 
5. Status* - IP ("In Progress") or Final 


6. Package name, Reference, and Contact information 


IANA will maintain the currency and public availability of the 
tabulation of public and private Packages. Packages will be listed 
in increasing order of serial number. The latest Package version 
will be entered, replacing the previous version in the registry. 
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6.2. IANA Error Code Registration 


On the request for an Error Code registration, the IANA shall forward 
the received information (i.e., the Error Code text and required 
Specification) to the IESG-appointed expert for review (see Section 
ovy). 
When instructed by the IESG-appointed expert, the IANA shall register 
the following information in the "H.248/MEGACO Packages" registry as 
described below: 
1. Error Code Number 
2. Error Code Text String 
3. Reference 

6.3. IANA ServiceChange Reason Registration 
On the request for a ServiceChange Reason registration, the IANA 
shall forward the received information (i.e., the ServiceChange 
Reason text and required specification) to the IESG-appointed expert 
for review (see Section 5.4). 
When instructed by the IESG-appointed expert, the IANA shall register 
the following information in the "H.248/MEGACO Packages" registry as 
described below: 
1. ServiceChange Reason Number 
2. ServiceChange Reason Text String 
3. Reference 

6.4. IANA Profile Name Registration 
On the request for a Profile Name registration, the IANA shall 
forward received information to the IESG-appointed expert for review 
(see Section 5.5). 
When instructed by the IESG-appointed expert, the IANA shall register 


the following information in the "H.248/MEGACO Packages" registry as 
described below: 


Groves & Lin Best Current Practice [Page 12] 


RFC 5615 


H.248/MEGACO Registration Procedures August 2009 


1. Profile Name 


2. Version 


3. Reference/Contact 
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